home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-atm-classic-ip-00.txt < prev    next >
Text File  |  1993-06-16  |  25KB  |  620 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.  
  8. Network Working Group                                       Mark Laubach
  9. Request for Comments: DRAFT                 Hewlett-Packard Laboratories
  10. Expires December 7, 1993                                    June 7, 1993
  11.  
  12.  
  13.                      Classical IP and ARP over ATM
  14.  
  15.  
  16. Positioning note for Readers
  17.  
  18.    [This section to be removed after draft is reviewed a few times.]
  19.  
  20.    This document is the deliverable from an action item made at the
  21.    Columbus IETF IP-over-ATM working group meeting on 3/28-3/30, 1993.
  22.    In that meeting, the group enthusiastically (with applause) agreed to
  23.    segment activities into two areas of focus: one is the treatment as
  24.    ATM as a "wire replacement" for connecting IP host and routers,
  25.    maintaining the current IP, ARP, and subnet architecture. This was
  26.    dubbed the "classical" approach. The other focus area is the world
  27.    where ATM subnets and peernets are widely deployed and globally
  28.    connected, where the architecture of IP and ARP will need to change
  29.    to take advantage of the features provided to it by this fully
  30.    deployed ATM.
  31.  
  32.    It was felt that writing down the "Classical IP over ATM"
  33.    specifications would be straightforward. This memo is a direct result
  34.    of that action item and hopes to be the "starting block" for the
  35.    efforts to come. Future memos will be forthcoming from the working
  36.    group that update or obsolete this one as ATM becomes better defined
  37.    and more fully deployed.
  38.  
  39.    The main differences between "classical" and "subnet/peernet" models
  40.    are:
  41.  
  42.    Classical
  43.  
  44.     o  One default maximum MTU size for the interface, consistent with
  45.        current implementations.
  46.  
  47.     o  Default LLC/SNAP encapsulation, with administrator allowed re-
  48.        configuration.
  49.  
  50.     o  IP destinations map to VC's via ARP and route lookups, consistent
  51.        with current model.
  52.  
  53.     o  ARP's stay within the LIS, current ARP architecture stays the
  54.        same.
  55.  
  56.  
  57.  
  58.  
  59. Laubach                                                         [Page 1]
  60.  
  61. DRAFT                Classical IP and ARP over ATM              May 1993
  62.  
  63.  
  64.     o  One IP subnet used for many hosts/routers. A separate VC is used
  65.        for each host/router pair, one subnet is used for all these VC's.
  66.  
  67.     o  PVC's dominate, we're stuck with them for awhile.
  68.  
  69.     o  Standard ATM signalling is non-existent.
  70.  
  71.    Subnet/Peernet:
  72.  
  73.     o  MTU size negotiated per VC via ATM signalling, requires MTU size
  74.        be separated from interface in protocol stack.
  75.  
  76.     o  Encapsulation negotiated per VC via ATM signalling, requires
  77.        common signalling to be implemented and globally available.
  78.  
  79.     o  Any applications map to VC's, requires changes to TCP/UDP/IP to
  80.        allow ports to map directly on to VC's
  81.  
  82.     o  ARP's can go global, ARP architecture needs to change to support
  83.        a robust global client/server model.
  84.  
  85.     o  Differing QOS's will exist on a per application basis.
  86.  
  87.    The deployment of ATM into the internet community is beginning and
  88.    will take several years to implement. During this period, we expect
  89.    deployment to follow logical ("classical") IP subnet boundaries for
  90.    the following reasons:
  91.  
  92.     o  Administrators and managers of IP subnetworks will tend to
  93.        initially follow the same models as they currently have deployed.
  94.        The mindset of the community will change slowly over time as ATM
  95.        increases its coverage and builds its credibility.
  96.  
  97.     o  Policy administration practices rely on the security, access,
  98.        routing, and filtering capability of IP Internet gateways: i.e.
  99.        firewalls. ATM will not be allowed to "back-door" these
  100.        mechanisms until ATM provides better management capability than
  101.        the existing services and practices.
  102.  
  103.    The need for standardization for the "classical" approach is wide-
  104.    spread and urgently needed. It is the intent of this position note to
  105.    make the point that this memo should be moved quickly through the
  106.    working group and into the draft standards process.
  107.  
  108. Status of this Memo
  109.  
  110.    This document is an internet draft. Internet Drafts are working
  111.    documents of the Internet Engineering Task Force (IETF), its Areas,
  112.  
  113.  
  114.  
  115. Laubach                                                         [Page 2]
  116.  
  117. DRAFT                Classical IP and ARP over ATM              May 1993
  118.  
  119.  
  120.    and its Working Groups. Note that other groups may also distribute
  121.    working documents as Internet Drafts.
  122.  
  123.    Internet Drafts are draft documents valid for a maximum of six
  124.    months.  Internet Drafts may be updated, replaced, or obsoleted by
  125.    other documents at any time. It is not appropriate to use Internet
  126.    Drafts as reference material or to cite them other than as a "working
  127.    draft" or "work in progress".  Please check the lid-abstracts.txt
  128.    listing contained in the internet-drafts shadow directories on
  129.    nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.src.com, or
  130.    munnari.oz.au to learn the current status of any Internet Draft.
  131.  
  132. 1.  Abstract
  133.  
  134.    This memo describes an initial application of classical IP and ARP in
  135.    an ATM network environment configured as a logical IP subnetwork, or
  136.    "LIS" as described below and in [1]. This memo does not preclude the
  137.    subsequent development of ATM technology into areas other than an
  138.    LIS; specifically, as single ATM networks grow to replace many
  139.    ethernet local LAN segments and as these networks become globally
  140.    connected, the application of IP and ARP will be treated differently.
  141.    This document considers only the application of ATM a as a direct
  142.    replacement for the "wires" and local LAN segments connecting IP
  143.    end-stations and routers. Issues raised by MAC level bridging are
  144.    beyond the scope of this paper.
  145.  
  146. 3.  Acknowledgment
  147.  
  148.    This memo could not have come into being without the critical review
  149.    from Jim Forster of Cisco Systems, Drew Perkins of FORE Systems, and
  150.    Bryan Lyles and Steve Deering of XEROX PARC. The concepts and models
  151.    presented in [1], written by Dave Piscitello and Joseph Lawrence,
  152.    laid the structural groundwork for this work. This document could
  153.    have not been completed without the expertise of the IP over ATM
  154.    Working Group of the IETF.
  155.  
  156. 4. Conventions
  157.  
  158.    The following language conventions are used in the items of
  159.    specification in this document:
  160.  
  161.    o   MUST, SHALL, or MANDATORY -- the item is an absolute requirement
  162.        of the specification.
  163.  
  164.    o   SHOULD or RECOMMEND -- this item should generally be followed for
  165.        all but exceptional circumstances.
  166.  
  167.    o   MAY or OPTIONAL -- the item is truly optional and may be followed
  168.  
  169.  
  170.  
  171. Laubach                                                         [Page 3]
  172.  
  173. DRAFT                Classical IP and ARP over ATM              May 1993
  174.  
  175.  
  176.        or ignored according to the needs of the implementor.
  177.  
  178. 5.  Introduction
  179.  
  180.    The goal of this specification is to allow compatible and
  181.    interoperable implementations for transmitting IP datagrams and ARP
  182.    requests and replies over ATM Adaptation Layer 5 (AAL5)[6].
  183.    Currently, ATM standards are being defined in the ATM-FORUM, the
  184.    ITU-TSS (formally CCITT), and ANSI. ITU-TSS and ANSI are defining
  185.    standards for public ATM networks, ATM-FORUM defines public and local
  186.    aspects of ATM standardization. It is the intent of this document to
  187.    follow ATM-FORUM standards for the use of Classical IP within local
  188.    (non-public) networks.
  189.  
  190.    Initial deployment of ATM provides a LAN segment replacement for
  191.    ethernet networks and as wire-replacement for dedicated public
  192.    telecommunication lines between IP routers. In the former model,
  193.    local IP routers with one or more ATM interfaces will connect islands
  194.    of local ATM networks. ATM-FORUM compliant addressing will be used
  195.    within these local ATM networks. In the latter model, public ATM
  196.    networks will be used to connect IP routers, which in turn may or may
  197.    not connect to local ATM networks. Public networks will use ITU-TSS
  198.    and ANSI standards for addressing in ATM. ATM-FORUM compliant
  199.    addressing cannot be guaranteed in public ATM networks.
  200.  
  201.    The characteristics and features of ATM networks are different than
  202.    those found in LAN's:
  203.  
  204.    o   ATM provides a virtual circuit switched environment. VC setup may
  205.        be done on either a permanent (PVC) or dynamic (SVC) basis. SVC
  206.        call management signalling is performed via Q.93B implementations
  207.        [7].
  208.  
  209.    o   Data to be passed by a VC is segmented into 53 octet quantities
  210.        called cells (5 octets of ATM header and 48 octets of data). ATM
  211.        networks provide very low latency switching, high throughput, and
  212.        the ability to multiplex VCs of differing quality of service.
  213.  
  214.    o   Each VC carries a type which identifies a specific format for the
  215.        exchange of protocol data units (PDU's). These formats are called
  216.        ATM Adaptation Layers (AAL's) and are typed from 1 through 5.
  217.        AAL5 specifies a packet format with a maximum size of 65K user
  218.        data octets. Cells for an AAL5 PDU are transmitted first to last,
  219.        the last cell indicating end of PDU. ATM standards guarantee that
  220.        on a given VC AAL5 PDU's are not intermixed and that cell
  221.        ordering is preserved end-to-end.
  222.  
  223.    o   Multicast is not yet a conformance requirement of the ATM-FORUM.
  224.  
  225.  
  226.  
  227. Laubach                                                         [Page 4]
  228.  
  229. DRAFT                Classical IP and ARP over ATM              May 1993
  230.  
  231.  
  232.    o   ATM hardware addresses are based on NSAP's.
  233.  
  234.    This memo describes the initial deployment of ATM within "classical"
  235.    IP networks as a direct replacement for local area networks
  236.    (ethernets) and for IP links which interconnect routers, either
  237.    within or between administrative domains. "Classical" here refers to
  238.    the treatment of the ATM host adapter as a networking interface to
  239.    the IP protocol stack. This memo does not preclude the subsequent
  240.    evolution of ATM networks as they become more globally deployed and
  241.    interconnected and the evolution of TCP and IP to take advantage of
  242.    these changes - these will be the subject of future documents. This
  243.    memo does not address issues related to transparent data link layer
  244.    interoperability.
  245.  
  246.  
  247. 6.  IP Subnetwork Configuration
  248.  
  249.    This section describes the scenario for an ATM network that is
  250.    configured with one or more logical IP subnetworks, LIS's. The
  251.    scenario considers only directly connected IP hosts or routers.
  252.  
  253.    In the LIS scenario, each separate administrative entity configures
  254.    its hosts and routers within a closed logical IP subnetwork. Each LIS
  255.    operates and communicates independently of other LIS's over the same
  256.    ATM network. Hosts connected to ATM communicate directly to other
  257.    hosts within the same LIS. Communication to hosts outside of the
  258.    local LIS is provided via an IP router. This router would be a
  259.    station attached to the ATM network that may have been configured as
  260.    a member of two or more LIS's. This configuration results in a number
  261.    of disjoint LIS's operating over the same ATM network. Hosts of
  262.    differing IP subnets would communicate via an intermediate router
  263.    even though a direct virtual circuit between the two hosts may be
  264.    available over the ATM network.
  265.  
  266.    The requirements for IP member stations (hosts, routers) operating in
  267.    an ATM LIS configuration are:
  268.  
  269.    o   All members have the same IP network/subnet number.
  270.  
  271.    o   All stations within an LIS are accessed directly over the ATM
  272.        network.
  273.  
  274.    o   All stations outside of the LIS are accessed via a router.
  275.  
  276.    o   All members of an LIS must have a mechanism for resolving IP
  277.        addresses to ATM addresses via ARP [4].
  278.  
  279.    o   All members within a LIS MUST be able to communicate with all
  280.  
  281.  
  282.  
  283. Laubach                                                         [Page 5]
  284.  
  285. DRAFT                Classical IP and ARP over ATM              May 1993
  286.  
  287.  
  288.        other members in the same LIS; i.e., the topology is fully
  289.        meshed. There should be no administrative restrictions at the ATM
  290.        level that prevent VC's from operating between all pair of
  291.        stations.
  292.  
  293.    o If the ATM switching fabric supports hardware multicast addressing,
  294.        then a group address MUST be configured whose membership is the
  295.        set of all IP stations within the LIS. Furthermore, one VC SHALL
  296.        be configured on each member station using this group address and
  297.        dedicated for ARP queries/replies, and one VC SHALL be configured
  298.        on each member station using this group address for encapsulated
  299.        IP traffic (see section under Packet Format).
  300.  
  301.    The following list identifies a set of ATM specific parameters that
  302.    MUST be implemented in each IP station which would connect to the ATM
  303.    network. The parameter values MUST be user configurable:
  304.  
  305.    o   ATM Hardware Address (atm$ha). The ATM individual address of the
  306.        IP station. Each host must be configured to accept datagrams
  307.        destined for this address
  308.  
  309.    o   ATM ARP Request Address (atm$arp-req). The ATM hardware address
  310.        (unicast or multicast) to which ARP requests are to be sent.
  311.        Three cases are supported:
  312.  
  313.        1. atm$arp-req is atm$ha, the local machine ATM hardware address.
  314.           The local host may either consult its static ARP translation
  315.           table directly, or support ARP queries by loopback internally
  316.           or exter- nally via the ATM network. In the case of an
  317.           external loopback, a VC is dedicated specifically for ARP
  318.           queries and replies.
  319.  
  320.        2. atm$arp-req is the ATM hardware unicast address of an
  321.           individual ARP server located within the LIS. That server must
  322.           have authorita- tive responsibility for resolving ARP requests
  323.           all IP stations within the LIS. The VC's connecting IP
  324.           stations to this ARP server are dedicated specifically for ARP
  325.           queries and replies.
  326.  
  327.        3. atm$arp-req is an ATM hardware group address. If the ATM
  328.           switching fabric supports ATM hardware multicast, then a well
  329.           known VC using the ATM group address local to the LIS is
  330.           dedicated specifically for broadcast ARP queries and replies.
  331.           The ARP query/reply service on all IP stations within the LIS
  332.           MUST be reachable via this address.
  333.  
  334.    ATM hardware addresses are formatted as ATM-FORUM compliant NSAP's.
  335.    [ref?]
  336.  
  337.  
  338.  
  339. Laubach                                                         [Page 6]
  340.  
  341. DRAFT                Classical IP and ARP over ATM              May 1993
  342.  
  343.  
  344.    ARP request and reply formats are discussed in the section on Address
  345.    Resolution.
  346.  
  347.    It is RECOMMENDED that routers providing LIS functionality over the
  348.    ATM network also support the ability to interconnect differing LIS's.
  349.    Routers that wish to provide interconnection of differing LIS's MUST
  350.    be able to support multiple sets of these parameters (one set for
  351.    each connected LIS) and be able to associate each set of parameters
  352.    with a specific IP network/ subnet number. In addition, it is
  353.    RECOMMENDED that a router be able to provide this multiple LIS
  354.    support with a single physical ATM interface that may have one or
  355.    more individual ATM addresses.
  356.  
  357. 7.  Packet Format
  358.  
  359.    The default packet format for IP datagrams SHALL be the IEEE 802.2
  360.    LLC/SNAP format as described in [2].
  361.  
  362.    This memo recognizes the future development of end-to-end signalling
  363.    within ATM that will allow negotiation of encapsulation method on a
  364.    per-VC basis. Signalling negotiations are beyond the scope of this
  365.    document.
  366.  
  367. 8.  MTU Size
  368.  
  369.    The default MTU size for IP stations operating over the ATM network
  370.    SHALL be 9180 octets. The LLC/SNAP header is 8 octets, therefore the
  371.    maximum ATM AAL5 protocol service unit size will be 9188 octets.
  372.  
  373.    The minimum IP MTU size is 576 octets [8]. The LLC/SNAP header is 8
  374.    octets, therefore the minimum ATM AAL5 protocol data unit size will
  375.    be 584 octets.
  376.  
  377.    This memo recognizes the future development of end-to-end signalling
  378.    within ATM that will allow negotiation of MTU on a per-VC basis.
  379.    End-to-end negotiations are beyond the scope of this document.
  380.  
  381. 9.  Address Resolution
  382.  
  383.    The dynamic mapping of 32-bit Internet addresses to ATM addresses
  384.    SHALL be done via the dynamic discovery procedure of the Address
  385.    Resolution Protocol (ARP) [3].
  386.  
  387.    Internet addresses are assigned independent of ATM addresses. Each
  388.    host implementation MUST know its own internet address and ATM
  389.    address and respond to Address Resolution requests appropriately.
  390.    Hosts MUST also use ARP (either dynamically or via static table
  391.    lookup) to map Internet addresses to ATM addresses when needed.
  392.  
  393.  
  394.  
  395. Laubach                                                         [Page 7]
  396.  
  397. DRAFT                Classical IP and ARP over ATM              May 1993
  398.  
  399.  
  400.    The ARP protocol has several fields that have the following format
  401.    and values:
  402.  
  403.        Data:
  404.            ar$hrd     16 bits        Hardware type
  405.            ar$pro     16 bits        Protocol type
  406.            ar$hln      8 bits        Octet length of hardware address (n)
  407.            ar$pln      8 bits        Octet length of protocol address (m)
  408.            ar$op      16 bits        Operation code (request or reply)
  409.            ar$sha     noctets        source hardware address
  410.            ar$spa     moctets        source protocol address
  411.            ar$tha     noctets        target hardware address
  412.            ar$tpa     moctets        target protocol address
  413.  
  414.        Where:
  415.            ar$hrd  -  assigned to NSAP address family and is nn decimal
  416.                       (0x00nn) [4].
  417.  
  418.            ar$pro  -  see Assigned Numbers for protocol type number for
  419.                       the protocol using ARP. (IP is 0x0800).
  420.  
  421.            ar$hln  -  length of the larger of the source or target
  422.                       hardware NSAP address length.
  423.  
  424.            ar$pln  -  length in bytes of the protocol address field. For
  425.                       IP ar$pln is 4.
  426.  
  427.            ar$op   -  1 for request and 2 for reply
  428.  
  429.            ar$sha  -  source NSAP address.
  430.  
  431.            ar$tha  -  target NSAP address.
  432.  
  433.    The ATM hardware addresses in ARP packets (ar$sha, ar$tha) SHALL be
  434.    ATM-FORUM specified NSAP addresses.[ref?]
  435.  
  436.    The same NSAP encoding SHALL be used within an LIS and replies will
  437.    use the same encoding as queries. For example, NSAP's may encode IEEE
  438.    48-bit MAC addresses or may encode E.164 addresses. Within the LIS
  439.    either IEEE MAC or E.164 hardware addresses may be used but not both.
  440.  
  441.    ARP packets are to be encoded in AAL5 PDU's using LLC/SNAP
  442.    encapsulation. The format of the AAL5 CPCS-SDU payload field for
  443.    routed non-ISO PDU's is:
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450.  
  451. Laubach                                                         [Page 8]
  452.  
  453. DRAFT                Classical IP and ARP over ATM              May 1993
  454.  
  455.  
  456.                Payload Format for Routed non-ISO PDU's
  457.                +------------------------------+
  458.                |        LLC 0xAA-AA-03        |
  459.                +------------------------------+
  460.                |        OUI 0x00-00-00        |
  461.                +------------------------------+
  462.                |     Ethertype 0x08-06        |
  463.                +------------------------------+
  464.                |                              |
  465.                |         ARP Packet           |
  466.                |                              |
  467.                +------------------------------+
  468.  
  469.    The LLC value of 0xAA-AA-03 (3 bytes) indicates the presence of a
  470.    SNAP header.
  471.  
  472.    The OUI value of 0x00-00-00 (3 bytes) indicates that the following
  473.    two-bytes is an ethertype.
  474.  
  475.    The Ethertype value of 0x08-06 (2 bytes) indicates ARP [4].
  476.  
  477.    The total size of the LLC/SNAP header is 8-bytes fixed length. This
  478.    aligns the start of the ARP packet on a 64-bit boundary relative to
  479.    the start of the AAL5 SDU.
  480.  
  481.    The LLC/SNAP encapsulation for ARP presented here is consistent with
  482.    the treatment of multiprotocol encapsulation of IP over ATM AAL5 as
  483.    specified in [2] and in the format of ARP over IEEE 802 networks as
  484.    specified in [5].
  485.  
  486.    Traditionally, ARP requests are broadcast to all directly connected
  487.    IP stations within a LIS. It is conceivable in the future that larger
  488.    scaled ATM networks may "broadcast" ARP requests to destinations
  489.    outside the originating LIS, perhaps even globally; issues raised by
  490.    broadcasting outside the LIS or by a global ARP mechanism are beyond
  491.    the scope of this document.
  492.  
  493. 10.  IP Broadcast Address
  494.  
  495.    ATM hardware multicast is not yet a conformance requirement of the
  496.    ATM-FORUM. As such, there is no consistent facility in ATM switches
  497.    for hardware multicast addressing. The following scenarios apply to
  498.    the multicast and non-multicast situations:
  499.  
  500.    1.  ATM multicast available: if the switch fabric connecting the host
  501.        ATM interface supports multicast, then the Internet broadcast
  502.        address (the address on that network with a host part of all
  503.        binary ones) MUST map to an ATM group address that includes all
  504.  
  505.  
  506.  
  507. Laubach                                                         [Page 9]
  508.  
  509. DRAFT                Classical IP and ARP over ATM              May 1993
  510.  
  511.  
  512.        IP stations within the LIS.
  513.  
  514.    2.  No ATM multicast support: the Internet broadcast address MUST map
  515.        to atm$arp-req, and atm$arp-req MUST either map to the local IP
  516.        host ATM hardware address or the ATM hardware address of an ARP
  517.        server located within the LIS.
  518.  
  519.    In either case, encapsulated IP packets sent to the IP broadcast
  520.    address may be received on the ARP query VC. This requires that IP
  521.    packets sent to the IP broadcast address use LLC/SNAP encoding and
  522.    that all stations examine the value of ethertype in the LLC/SNAP
  523.    header and process IP versus ARP accordingly on all packets received
  524.    on this VC.
  525.  
  526. 11.  IP Multicast Address
  527.  
  528.    IP multicast address mapping to ATM group addresses are not discussed
  529.    in this memo.
  530.  
  531. 12.  Security
  532.  
  533.    Security issues are not discussed in this memo.
  534.  
  535.    This memo recognizes the future development of ATM and IP facilities
  536.    for authenticated call setup, authenticated end-to-end application
  537.    knowledge, and data encryption as being required services for
  538.    globally connected ATM networks. These future security facilities and
  539.    their use by IP networks are beyond the scope of this document.
  540.  
  541. 13.  Open Issues
  542.  
  543.    [This section to be removed after draft is reviewed a few times.]
  544.  
  545.    There are some open issues:
  546.  
  547.    o   A proposal was put before the Internet Assigned Numbers Authority
  548.        to approve a request to create an ARP hardware type of "NSAP
  549.        family address".  IANA has not responded as of this date.  My
  550.        hopes are that we can get an ARP type created now that will cover
  551.        NSAPs for all time.
  552.  
  553.    o   Well known ATM hardware address(es) for ARP servers?  It would be
  554.        very handy if we came up with a set of well known ATM addresses
  555.        for ARP services.  We should probably have well-known PVC numbers
  556.        for a non-SVC environment also.
  557.  
  558.    o   Should this require that Interim Local Management Interface
  559.        (ILMI) be used to obtain the ATM address network prefix from the
  560.  
  561.  
  562.  
  563. Laubach                                                        [Page 10]
  564.  
  565. DRAFT                Classical IP and ARP over ATM              May 1993
  566.  
  567.  
  568.        network?
  569.  
  570.    o   We need to be able to reference ATM-FORUM documents within this
  571.        memo, are these publicly released?  If yes, what are the
  572.        references?
  573.  
  574. REFERENCES
  575.  
  576.    [1] Piscitello, D., and Lawrence, J., "IP and ARP over the SMDS
  577.        Service", RFC1209, USC/Information Sciences Institute, March
  578.        1991.
  579.  
  580.    [2] Heinanen, Juha, "Multiprotocol Encapsulation over ATM Adaptation
  581.        Layer 5", work in progress, IETF IP over ATM Working Group,
  582.        February 1993.
  583.  
  584.    [3] Plummer, D., "An Ethernet Address Resolution Protocol - or -
  585.        Converting Network Addresses to 48.bit Ethernet Address for
  586.        Transmission on Ethernet Hardware", RFC 826, MIT, November 1982.
  587.  
  588.    [4] Reynolds, J., and Postel, J., "Assigned Numbers", RFC1340, USC/
  589.        Information Sciences Institute, July 1992.
  590.  
  591.    [5] Postel, J., and Reynolds, J., "A Standard for the Transmission of
  592.        IP Datagrams over IEEE 802 Networks", RFC1042, USC/Information
  593.        Sciences Institute, February 1988.
  594.  
  595.    [6] CCITT, "Draft Recommendation I.363", CCITT Study Group XVIII,
  596.        Geneva, 19-29 January 1993.
  597.  
  598.    [7] CCITT, "Draft text for Q.93B", CCITT Study Group XI, 23 September
  599.        - 2 October 1992.
  600.  
  601.    [8] Braden, R., "Requirements for Internet Hosts -- Communication
  602.        Layers", RFC1122, USC/Information Sciences Institute, October
  603.        1989.
  604.  
  605.    [Need ATM-FORUM references.]
  606.  
  607. Authors' Addresses
  608.  
  609.    Mark Laubach
  610.    Hewlett-Packard Laboratories
  611.    1501 Page Mill Road
  612.    Palo Alto, CA 94304
  613.  
  614.    Phone: 415.857.3513             FAX: 415.857.8526
  615.    EMail: laubach@hpl.hp.com
  616.  
  617.  
  618.  
  619. Laubach                                                        [Page 11]
  620.